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Summary 


Data exchange is an increasingly important aspect of the National Airspace System. While many 
data communication channels have become more capable of sending and receiving data at higher 
throughput rates, there is still a need to use communication channels efficiently with limited 
throughput. The limitation can be based on technological issues, financial considerations, or 
both. This paper provides a complete description of several important aviation weather data in 
Abstract Syntax Notation format. By doing so, data providers can take advantage of Abstract 
Syntax Notation’s ability to encode data in a highly compressed fonnat. When data such as pilot 
weather reports, surface weather observations, and various weather predictions are compressed 
in such a manner, it allows for the efficient use of throughput-limited communication channels. 
This paper provides details on the Abstract Syntax Notation One (ASN.l) implementation for 
Alaskan aviation data, and demonstrates its use on real-world aviation weather data samples as 
Alaska has sparse terrestrial data infrastructure and data are often sent via relatively costly 
satellite channels. 

1. Introduction 

Alaska is a unique environment. This is especially true in the world of aviation. Due to the lack 
of ground-based transportation infrastructure, there is a heavy dependence on aviation for the 
movement of people and goods throughout this massive state. When this dependence on aviation 
is coupled with extreme weather and mountainous terrain, there is a marked increase in aviation 
accidents in Alaska on a per-operation basis compared to the conterminous United States [1]. 

The need to increase aviation safety in Alaska has been well recognized. A report on the 
occupational dangers of flying in Alaska has been documented by the Centers for Disease 
Control and Prevention (CDC) [2]. A major engineering and research endeavor called “Cap- 
stone” was undertaken to evaluate the use of new technology to reduce accidents in Alaska [3]. 
In addition, the National Transportation Safety Board (NTSB) has recognized the general need 
for improved situational awareness for general aviation by issuing the challenge to “identify and 
communicate hazardous weather” as part of its “Most Wanted List” for 2014 [4], 

With this background, NASA and the state of Alaska agreed to cooperate on fundamental 
research and development of a system aimed at providing general aviation pilots in Alaska 
improved situational awareness through the use of commercial off-the-shelf technologies. The 
project is named Traffic and Atmospheric Information for General Aviation (TAIGA). The high- 
level concept of the project is to create infrastructure, data retrieval, and processing, plus 
interface software using currently available data sources of interest and importance to general 
aviation pilots in Alaska. Pilots would receive the messages via a sensor device that includes at 
least a satellite receiver and potentially other sensors (global positioning system (GPS), 
Automatic Dependent Surveillance-Broadcast (ADS-B) in, altimeter, etc.) and then interact with 
the received data on a commercial mobile device, such as an iPad or Android-based tablet. 
Several aspects of this project are proceeding in parallel. The work presented here is concerned 
with the specification of the messages that are sent via satellite from a ground station to the 
pilot’s receiving device. 


1 



Because the cost of sending such messages via satellite may be considerable, it is important to 
have efficient data encoding. The data need to be as complete as possible with minimal 
redundancies and non-essential information. This document discusses the various trade-offs 
proposed to strike such a balance between completeness and efficiency. Note that a major 
motivation for this document is to allow public comment on work that has been heretofore 
NASA-only research. The specification presented here is current as of publication of this 
document and is subject to significant revision once comments from stakeholders are received. In 
the future, there will be a formal release of the specification along with processes to keep the 
specification up to date. 

The remainder of this document is organized as follows: Section 2 provides background on some 
of the data that are proposed to be communicated via this system, namely Pilot Weather Reports 
(Section 2.1), Aviation Surface Weather Reports (Section 2.2), and Generic Weather Polygons 
(Section 2.3). Then an introduction to Abstract Syntax Notation One (ASN.l), which is used to 
formally specify the messages within TAIGA broadcasts, is provided in Section 3. Next, a dis- 
cussion of the encoding choices for the various message types is given in Section 4. Concluding 
remarks are provided in Section 5, followed by two important appendices. In Appendix A, the 
proposed ASN.l specification for the messages is provided in its current state as of the 
publishing of this document. Finally, Appendix B provides concrete examples of the encoding. 

2. Background 

This section provides background information relevant to the development of the data 
descriptions described later in this document. Specifically, a high-level view of the format and 
content of aviation weather data including Pilot Weather Reports (PIREPs), Aviation Routine 
Weather Reports (METARs), and various weather predictions and observations are provided. 

2.1 Pilot Weather Reports 

Pilots rely on reports from other pilots to aid in flight planning and situational awareness during 
flight. The formal mechanism for reporting weather information by pilots is the Pilot Weather 
Report or PIREP [5]. These reports contain information about turbulence, wind, visibility, icing, 
and temperature, as well as information about the aircraft and location involved with the report. 
Typically, these PIREPs are solicited by Flight Service Stations (FSSs) or pilots offer them freely 
to FSSs. These PIREPs are then entered into a central database for access by other FSSs or users 
via various web interfaces. The PIREPs may then become part of the briefing given during pre- 
flight planning or perhaps en route when requested by a pilot via radio. PIREPs are not typically 
available to en route pilots in an automated fashion. They were originally designed to be easily 
transmitted via voice over the radio. 
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TABLE 1 . SUMMARY OF PIREP WEATHER PHENOMENON ELEMENTS 


Phenomenon 

TEI 

Examples 

Turbulence 

TB 

/TB LGT 040, /TB MOD CHOP 220 

Air Temperature 

TA 

/TA 08, /TA M08 

Icing 

1C 

/ 1C LGT-MOD MX 085, / 1C SEV CLR 035-062 

Sky Condition 

SK 

/SK OVC-TOP085, /SK OVC015-TOP035 

Wind Direction and Speed 

WV 

/WV 28080KT, /WV010105KT 

Visibility and Weather 

wx 

/WX FV20SM, /WX FV10SM HZ 


Every PIREP includes the message type, time (TM), location (OV), altitude (FL), and aircraft 
type (TP) for the reporting aircraft. For this work, these elements are considered to describe the 
“header” for the PIREP. The message type is either routine (UA) or urgent (UUA). A PIREP is 
labeled urgent if it reports tornadoes, funnel clouds, waterspouts, severe or extreme turbulence, 
severe icing, hail, low-level wind shear, volcanic ash, or any other phenomenon considered 
hazardous by the flight services’ specialist. Time is reported in Universal Time, Coordinated 
(UTC) and represents when the reported phenomenon was encountered. The location is 
described in reference to a navigational aid or airport (or two such points in the case of route 
segments). The flight level is reported in hundreds of feet. Aircraft type is reported using the 
appropriate designator [6]. If the PIREP is reported by a pilot who has been certified as a 
“SKYSPOTTER” (one who has received specialized training), 7AWC’ is appended to the 
PIREP. 

Each element, except the leading message type element, is preceded by a solidus (/), thus cleanly 
dividing the various elements into distinct fields. Each element is officially referred to as a Text 
Element Identifier (TEI). 

The rest of the PIREP contains information about the weather phenomena being reported. Those 
phenomena are divided into one of six categories. A seventh “remarks” category describes 
additional details or phenomena not covered by the six categories. These categories are 
summarized in Table 1 and further detailed in the sections below. 

2.1.1 Turbulence Element 

The turbulence (TB) TEI has up to three components. The only required field is the intensity 
described as light, moderate, severe, or extreme. The abbreviations LGT, MOD, SEV, and 
EXTRM, respectively, are used to denote the intensities. These intensities may also be combined 
to show a range of intensity, such as LGT-MOD. If the pilot reports it, the PIREP will indicate if 
the turbulence is clear air turbulence (CAT), choppy (CHOP), or both. If the encounter with 
turbulence occurs at a different altitude than indicated in the /FL TEI, the /TB element may also 
include altitude information. For the two TB examples in Table 1, the first shows a report of light 
turbulence occurring at 4,000 feet, and the second shows moderate, choppy turbulence at 
22,000 feet. 

2.1.2 Air Temperature Element 

Air temperature (TA) is reported in degrees Celsius. The value is always described with two 
digits. For negative values, an “M” is prepended. 
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2.1.3 Icing Element 

Icing (IC) is described with an intensity, type, and optional flight level. The intensity is indicated 
as TRACE, LGT, MOD, or SEV. The type is rime, clear, or mixed, indicated by RIME, CLEAR, 
or MX, respectively. When icing is reported, the pilot is also required to supply a TA report, 
however this requirement is often overlooked in practicality. 

2.1.4 Sky Condition Element 

The Sky Condition (SK) TEI reports on cloud coverage. Descriptions of the cloud cover as 
broken, few, overcast, scattered, or sky clear are abbreviated as BKN, FEW, OVC, SCT, and 
SKC, respectively. In addition to this qualitative description, a range of flight levels (or just a 
top) is also provided. 

2.1.5 Wind Vector Element 

The Wind Vector (WV) TEI describes both the direction and speed of the wind at the reported 
time and location. The first three digits are used for the magnetic direction (000-359), and the 
next two to three digits indicate the speed in knots. A zero is prepended to a wind speed less than 
10 knots. Finally, the characters “KT” are appended to the element. 

2.1.6 Weather Element 

The WX element describes flight visibility, flight weather, or both. Visibility, if reported, is 
provided in statute miles (SM) and is indicated with a preceding “FV” followed by a two-digit 
value followed by “SM.” If visibility is unrestricted, a value of 99 is indicated. For weather 
types, the Federal Aviation Administration (FAA) provides a set of abbreviations to describe 40 
phenomena such as rain, drifting sand, shallow fog, and others. As an example, in Table 1 there 
is a report for haze (HZ). For precipitation phenomena, an intensity value may be indicated with 
a or *+’, describing light and heavy precipitation, respectively. For extreme weather 
phenomena, additional information may be required within the WX TEI or the remarks section. 
An altitude range may also be provided. 

2.1.7 Example PIREPs 

To provide a complete idea of what all of these elements look like in an actual PIREP, four 
examples, each with a brief description, are provided below. 

1 . UA /O V ILI047045/TM 00 1 3/FL2 1 0/TP SF34/TA M23/IC MOD RIME 

2. UUA /OV OMNI 15095/TM 0027/FL360/TP B737/TB SEV 

3. UA /OV FSD/TM 0236/FL100/TP PAT4/SK UNKN050-TOP067/TA M08/IC LGT MX 

4. UA /OV PIR/TM 0107/FL1 10/TP C208/WX -SN/TA M10/IC NEG 

The first PIREP is a routine PIREP (UA) reported at 47 degrees and 45 nmi from ILI 
(ILI047045) at 0013Z. The pilot was at flight level 210 in a Saab 340 turboprop (SF34). The 
pilot reported an air temperature of-23°C (M23) and moderate rime icing (MOD RIME). 

The second PIREP was urgent (UUA) reported at 115 degrees and 95 nmi from OMN 
(OMNI 15095) at 0027Z. The pilot was at flight level 360 in a Boeing 737. The report contains 
only one element: severe turbulence (TB SEV). Severe turbulence reports necessitate the tagging 
as urgent. 
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The third PIREP was reported over FSD at 0236Z while flying at flight level 100. From a Piper 
T-1040 (PAT4), the pilot reported a sky condition of “unknown” from flight levels 050 to 067 
(UNKN050TOP067). The air temperature was -8°C (M08), and there was light mixed (rime and 
clear) icing (LGT MX). 

The fourth and final PIREP shown here was flying over PIR at 0107Z. The pilot’s flight level 
was 110 in a Cessna 208 Grand Caravan (C208) when there was a report of light snow (-SN). 
There was no icing (IC NEG) and the air temperature was -10°C (M10). 

2.2 Aviation Surface Weather Reports 

The Surface Weather Observation Program collects and disseminates Aviation Routine Weather 
Reports (METARs) and Aviation Selected Special Weather Reports (SPECIs) using a set of 
observation stations managed by the National Weather Service. The stations may be automated 
or human operated, but the key weather elements that are provided within a METAR or a SPECI 
are essentially the same and are guided by rigid and formal standards. This section provides an 
overview of these surface weather reports. The interested reader is directed to the Federal 
Meteorological Handbook [7] from which all the information in this section was derived. 

Because the content of a METAR and a SPECI is essentially the same, the following references 
to METARs assume that both message types apply unless explicitly stated otherwise. Each 
METAR consists of exactly two major parts: a Body and a Remarks section. The Body contains 
up to 11 groups of data: 

1. Type or report 

2. Station identifier 

3. Timestamp 

4. Report modifier 

5. Wind 

6. Visibility 

7. Runway visual range 

8. Present weather 

9. Sky condition 

10. Temperature and dew point 

1 1 . Altimeter 

The first four elements in the preceding list could be considered a header that provides 
information describing the type of report (METAR or SPECI), station identifier (for example, an 
airport identifier), the time and date of the report, and whether the report is fully automated or 
manually corrected. The remaining elements are descriptions of actual observed weather 
conditions. Any element may be omitted from any given METAR. A brief description of some of 
the weather elements is provided in the following sections, and a few examples are shown in 
Table 2 to help ground the discussion. The Remarks section has two categories. 
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TABLE 2. SUBSET OF AVAILABLE METAR WEATHER ELEMENTS 


Phenomenon 

Examples 

Wind 

04007KT, 20003KT 

Visibility 

10SM, 3/4SM 

Runway Visual Range 

R09R/1 200V3000FT, R35L/P6000FT 

Present Weather 

-DZ, -RA BR 


The first is “Automated, Manual, and Plain Language Remarks.” Typically these remarks relate 
to the infonnation provided in the body by elaborating or further detailing the various weather 
phenomena. They may also provide more emergent messages such as volcanic activity/eruptions 
and funnel cloud activity. The second category includes “Additive and Maintenance” data. This 
includes additional meteorological data relating to precipitation (amount of precipitation at 
various timescales, snow depth, water equivalent of snow), cloud types, sunshine, hourly 
temperature, and dew point, among others. This second category also potentially contains 
information about the station itself, namely if it is in need of maintenance and the status of its 
sensors. 

2.2.1 METAR Wind 

The wind group describes the horizontal wind velocity at the station location. At a minimum, the 
wind group typically contains the direction and speed. In addition, any gusts, variations, shifts, 
and peak speeds may also be reported depending on conditions and the capabilities of the 
reporting station. Gusts are defined as a rapid fluctuation in wind speed with a variation from the 
reported speed of at least 10 knots. Peak wind speed is the maximum instantaneous wind speed 
since the last routine METAR. A wind shift is a change in direction of at least 45 degrees while 
maintaining wind speeds of at least 10 knots. A wind speed of less than 6 knots is considered 
variable, as is a wind speed of at least 6 knots with the wind varying by at least 60 degrees. 

2.2.2 METAR Visibility 

Visibility is provided in statute miles (SM). Automated stations provide visibility values in 1/4 
SM steps up to 2 SM, then in 1/2 SM steps up to 3 SM, then in 1 SM steps up to 10 SM. Manual 
visibility reports may vary in 1/16 SM steps up to 3/8 of an SM and then in 1/8 SM steps up to 
2 SM, then in 1/4 SM steps up to 3 SM, then in 1 SM steps up to 15, and then in 5 SM steps 
thereafter. A modifier ‘M’ may be prepended to indicate “less than” for the provided 
measurement, usually on the minimal reportable value. For example, for visibility less than 1/4 
SM, an automated station would report “M 1/4.” 

2.2.3 METAR Runway Visual Range 

“The runway visual range (RVR) is the maximum distance at which the runway, or the specified 
lights or markers delineating it, can be seen from a position above a specified point on its center 
line” [7]. RVR is measured in feet. Up to 1,000 feet, the steps are 100 feet, then up to 3,000 feet 
a step size of 200 feet is used, and finally, values between 3,000 and 6,000 use a step size of 500 
feet. The runway number is also included with the RVR, separated from the value with a solidus 
7’. If the RVR is varying over the report period, the range of variation is reported using a ‘V’. 
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QUALIFIER 

WEATHER PHENOMENA 

INTENSITY OR 
PROXIMITY 

DESCRIPTOR 

PRECIPITATION 

OBSCURATION 

OTHER 

1 

2 

3 

4 

5 

- Light 

MI Shallow 

DZ Drizzle 

BR Mist 

PO Well- 
Developed 

Moderate 2 

PR Partial 

RA Rain 

FG Fog 

Dust/Sand 

Whirls 

+ Heavy 

BC Patches 

SN Snow 

FU Smoke 

SQ Squalls 

VC In the 
Vicinity 3 

DR Low Drifting 

SG Snow Grains 

VA Volcanic Ash 

FC Funnel Cloud 


BL Blowing 
SH Shower(s) 

TS Thunderstorm 
FZ Freezing 

IC Ice Crystals 

PL Ice Pellets 

GR Hail 

GS Small Hail 
and/or Snow 
Pellets 

UP Unknown 
Precipitation 

DU Widespread 
Dust 

SA Sand 

HZ Haze 

PY Spray 

Tornado 

Waterspout 4 

SS Sandstorm 

DS Duststorm 

1 . The weather groups shall be constructed by considering columns 1 to 5 in the table above in sequence, 

1. e., intensity, followed by description, followed by weather phenomena, e.g., heavy rain shower(s) is 
coded as +SHRA 

2. To denote moderate intensity no entry or symbol is used. 

3. See paragraph 8.4.1. a.(2), 8.5, and 8.5.1 for vicinity definitions. 

4. Tornadoes and waterspouts shall be coded as +FC. 


Figure 1. METAR present weather values [7], 


2.2.4 METAR Present Weather 

The present weather section describes “precipitation, obscurations, well-developed dust/sand 
whirls, squalls, tornadic activity, sandstorms, and dust storms. Present weather may be evaluated 
instrumentally, manually, or through a combination of instrumental and manual methods” [7]. 
The list of codes to successfully describe this collection of meteorological activities is quite long. 
The list of these activities is essentially the set of all legal combinations of the elements shown in 
Figure 1, which is cropped directly from the National Oceanic and Atmospheric Administration 
(NOAA) manual [7] regarding METARs. 

2.3 Weather Polygons 

Weather phenomena are typically described in relation to geographic locations. These locations 
are often times areas that are affected by the phenomena being described. As such, geographic 
polygons with associated data are a natural way to fully describe the weather phenomena. 

Some examples from the Alaska Aviation Weather Unit are provided next. The first, Figure 2, is 
a graphic describing the forecast for icing over Alaska. The second, Figure 3, shows a similar 
graphic for the current turbulence prediction. Finally, Figure 4 provides the prediction of 
conditions in terms of flight rules: Instrument Flight Rules (IFR), Visual Flight Rules (VFR), or 
Marginal VFR (MVFR). Note that areas in Figure 4 are VFR except where designated as IFR or 
MVFR specifically. 

The important thing to note from each of these images is that they can be described with a set of 
polygons and associated data. For example, the icing forecast would need the vertices (or 
appropriate approximations thereof) or each polygon along with the descriptor for each polygon. 
In the legends of Figures 2 and 3, “ISOL MOD” means “isolated moderate” and “MOD ISOL 
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SEV” means “moderate isolated severe.” The diagrams also include appropriate time information 
(issue time and valid times). 


There are several weather phenomena (thunderstorm activity, volcanic activity, and many others) 
that fit this data description model of polygon-description- times. 



VALID 

09 May 2014 1200 to 
10 May 2014 0000 UTC 


ICING FORECAST SUMMARY 

NOAA - NWS ALASKA AVIATION WEATHER UNIT 


ISSUED 
09 May 2014 
04 AM AKDT 


Figure 2. Icing prediction from the Alaska Aviation Weather Unit. 
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FL180 & BELOW 

□ iSOL MOD 

□ OCNLTO CONS MOD 
■ MOD ISOL SEV 

ABOVE FL180 

□ OCNLTO CONS MOD 


valid SFC to FL450 issued 

09 May 2014 1200 to 09 May 2014 

10 May 2014 0000 UTC NOAA - NWS ALASKA AVIATION WEATHER UNIT 05 AM AKDT 




TURBULENCE FORECAST SUMMARY 


Figure 3. Turbulence prediction from the Alaska Aviation Weather Unit. 
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Figure 4. Flight category prediction from the Alaska Aviation Weather Unit. 

Certain aviation elements can also be described with this pattern. For example, a Special Use 
Airspace could use this data description pattern as well. 

3. Abstract Syntax Notation One 

To fully describe Abstract Syntax Notation One (ASN.l) would require several chapters of a 
textbook. As such, the interested reader is directed to the works of Dubuisson [8] and Larmouth 
[9] for a more complete description. A brief description is provided here to ground the future 
discussion of these implementations. 

ASN. 1 is a notation system to formally describe data messages for exchange between computer 
systems. ASN.l can be a means to completely describe a messaging protocol. Several widely 
adopted protocols are formally described with ASN.l including Radio-Frequency Identification 
(RFID), Lightweight Directory Access Protocol (LDAP), and Aeronautical Telecommunication 
Network (ATN), among others. ASN.l also provides a set of encoding rules to create well- 
defined instances of messages adhering to the protocol’s ASN.l specification. Simply stated, 
ASN.l provides the rules for describing the content of messages as well as the specific rules for 
encoding those messages as bits, bytes, or strings, depending on the type of encoding desired. 

One of the benefits of using ASN. 1 is the fact that it frees the protocol developer and protocol 
implementer from designing the specification of the messaging application as well as the 
encodings for the implementation of the messaging application. Various encoding rules 
associated with ASN.l include basic encoding rules (BER), XML encoding rules (XER), and 
packed encoding rules (PER), among others. BER is based on collections of triplets of the form 
(Type, Length, Value) that are ultimately encoded as octets (bytes). XER encodes the data as 
XML. PER is the most efficient in terms of message length as all data are put into binary form 
taking advantage of look-up tables for constrained data and potentially (in the unaligned version 
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of PER or “UPER”) ignoring the concept of bytes to write data values across byte boundaries 
without “wasted” bits within bytes. UPER will be used to efficiently encode the various data in 
this study. 

To provide some additional context, the following example (modified from Oliver Dubuisson’s 
ASN.l book [8]) may be illustrative. 

Payment-method ::= CHOICE { 

check NumericString (SIZE (15)), 

credit-card Credit-card, 

cash NULL } 

Credit-card ::= SEQUENCE { 

type Card-type, 

number NumericString (SIZE (20)), 

code INTEGER (0..999) OPTIONAL , 

expiration-date UTCTime } 

Card-type ::= ENUMERATED { mastercard ( 0 ) , visa(l), eurocard(2), diners (3), 

american-express (4), other (5) } 


This example describes a payment system. The top level element is a choice of payment methods 
(check, credit card, or cash). The “check” option only requires the number on the check as 
further data, and the cash option requires no further data. Note that the “credit card” option is 
described by another data structure because there are several data elements needed to describe it. 
If the Payment-method is a credit card, then the type of the card, the number on the card, the 
code on the back of the card, and the expiration date are all needed. The Card-type is an 
enumeration of options, the number is a string of 20 digits, and the code on the reverse is 
optional and must be between 0 and 999. It is through a set of such definitions that one 
formalizes a data description in ASN.l. With such a formalization, one is able to encode 
instances of such data elements using the various encoding schemes discussed above. A 
particular payment method by credit card could be encoded as an XML document (XER 
encoding rules for ASN.l), squeezed down to a bit string as tightly as possible (UPER encoding 
rules for ASN.l), or some other encoding as allowed within the ASN.l specification. 

4. Data Descriptions 

The formal ASN.l specifications for TAIGA are provided in Appendix A. This section discusses 
those specifications with an emphasis on the differences between TAIGA and existing 
descriptions of the same data. Of particular interest are the differences between the formal, 
operational data descriptions for PIREPs and METARs and why those differences exist in the 
TAIGA ASN.l specification. In general, differences only exist for the sake of efficient 
transmission of the various data. If data compression was not the central concern, the most basic 
ASN. 1 specification for the TAIGA data would be to encode, say, a PIREP as a string and just 
transmit the existing PIREP as that string without altering it. That naive approach would not 
allow for any compression of the original data. By understanding the redundancies and other 
qualities of the data, a specification was created that allows for highly efficient data encoding. 
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4.1 Encoding Locations 


Location infonnation is central to describing any weather or aviation phenomenon. In many 
aviation applications, locations are described by named infrastructure like airports or 
navigational aids (NAVAIDs). For example, a PIREP is described relative to such locations in 
terms of a radial (direction in degrees from true north) and a distance in nautical miles. So a 
PIREP reported 31 nautical miles due west (270 degrees) from Ted Stevens International Airport 
in Anchorage (ANC) would be described as ANC270031 in the PIREP. For METARs the 
location is indicated only by a station identifier. Transmitting just those data would require a 
client system to have access to all known named locations and their mapping to latitude- 
longitude (lat-lon) values for visualization on a modem user interface. 

This approach to describing locations also varies significantly from the approach used to describe 
other aviation-related features, such as weather prediction polygons and the like. For example, to 
describe a turbulence forecast, typically there would be a set of vertices describing the polygon 
that will be affected. These vertices would be described as lat-lon pairs, with no reference to 
aviation infrastructure. The messaging scheme presented here attempts to unify location 
descriptions for more consistent data encoding and efficiency in message delivery. 

The chosen approach is called “Geohashing” and it is a well-known method of encoding lat-lon 
pairs. The approach bisects the globe laterally and longitudinally a set number of times. 
Depending on which side of the bisection the target point lies, a 1 or 0 (also known as a ‘bit’) is 
used to designate that location. The more bisections that are done, the more accurate the geohash 
encoding and the longer the string of bits used in the encoding. After the desired accuracy is 
obtained, the bits for the horizontal and vertical bisections are interleaved. The reason for 
interleaving is that any bits removed from the tail of the string will leave the location information 
intact, but with less accuracy/resolution. The new interleaved string of bits is then grouped into 
sets of 5 bits each. Those 5 bits are mapped to an alphabet of 32 characters (recall that 2 = 32). 
The resulting character string is how the location data are ultimately encoded and transferred. 

In Appendix A, Section A.2, the characters for this encoding are shown and the above 
description is provided again. In Appendix B, Section B.3, an example of encoded points of 
various resolutions is provided. 

4.2 Encoding Time 

Temporal information is also a key feature of most aviation data. As such, data related to time 
are present in nearly all the information that may be transmitted using the encodings described in 
this document. To make the encoding and transmission of temporal data as efficient as possible, 
a “reference time and offset” approach is taken with this system. For each message a reference 
time is provided in the header. This reference time is always in UTC. Rather than provide a date 
with each message, a reference day is provided. To provide a date, one needs to be able to 
encode 31 values for the day of the month, potentially 12 values for the month, and some value 
to represent the year. Even if the decision was to encode just the day of the month, that would 
require 5 bits of information, whereas to encode a choice of 7 days of the week requires only 3 
bits. Because nearly all (potentially all) of the data is temporary in nature and does not have a 
shelf life over 24 hours, using the day of the week seems appropriate enough. If examples appear 
in the future where this type of encoding becomes problematic, the issue can be revisited. 
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Given the reference time (and day) provided in the header, all times that are used in any payload 
are described relative to this reference time. As such, the reference time needs to be the earliest 
time that might be needed by any data element across all the payloads in a given message. After 
that is determined, when a time is described, only the number of 10-minute steps (or ‘ticks’) 
since the reference time are provided. For example, if the reference time is 0340 UTC, and a 
PIREP is reported for 0412UTC, that second time would be encoded as three 10-minute ticks 
since the reference time. Note that this introduces some loss in precision and only a guarantee 
that any given time is within 5 minutes of its actual time. For aviation data (specifically aviation 
weather) information, this level of precision seems appropriate. 

By using 10-minute ticks as the time description and using the assumption that 24 hours is the 
longest amount of time needed to encode for the data items in this schema, only 144 10-minute 
ticks are needed to cover that 24-hour period. This allows any time within any payload to be 
encoded with just 7 bits. 

4.3 ASN.1 PIREP Data 

The initial phase of this work focused on developing a method for compressing the data 
described by PIREPs. This was done without the benefit of ASN.l. In that work [10], 
compression ratios under 0.20 were achieved, which means that only 20 percent of the original 
bits needed to encode the data were required in the new approach. By extending that work to 
include several other data types (METARs, weather polygons, etc.) under a common ASN.l 
specification, a complete messaging system for general aviation can be developed. 

As described in the original PIREP compression paper, the approach is a lossy compression 
approach when compared to a raw PIREP. This loss in information is designed to be minimal in 
impact to the end user (pilot) by maintaining the most important elements of the PIREP while 
working to minimize data redundancies. The differences that occur between raw PIREP and a 
PIREP encoded via the proposed ASN.l specification are detailed in Table 3. The reasons behind 
these differences are discussed more qualitatively here. 

The differences in what we refer to as the PIREP header information that is common to all 
PIREPs (location, time, flight level, and aircraft type) are as follows. The location is described as 
a latitude and longitude pair rather than a reference point together with an optional radial and 
distance. This frees any client from needing to have a database of reference points (airports and 
NAVAIDs) to calculate a precise location on a map. For interacting and reading data on an 
electronic map, this seems like a reasonable approach. Theoretically, if a database of reference 
points were available on the client device, a radial and distance from a reference fix could be 
calculated from a lat-lon pair. This would be useful if pilots wanted to describe the point verbally 
or see a textual description not overlaid on a base map. Like most of the time stamps in this 
proposed specification, the time for a given PIREP is actually an offset from a time provided in 
the main header for the broadcast message. The offset steps are in 10-minute increments, thus the 
accuracy of the time will be within 10 minutes of the actual PIREP report time. The flight level is 
provided in hundreds of feet as is the standard for describing flight levels, however, this 
specification limits this (and all) flight level description to a maximum of flight level 511. In 
aviation most aircraft typically fly below 50,000 feet, so this upper bound seems reasonable. 
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TABLE 3. COMPARISON OF PIREP ENCODINGS 


Element 

Federal Standard [5] 

Difference in TAIGA Encoding 

Type 

Urgent or Routine 

- 

Location 

NAVAID or airport identifier, with 
potential radial and distance or route 
segment of two such points 

Latitude-Longitude pair with sub 
0.1 km precision. No segments 
allowed. 

Time 

4-digit UTC time 

Time accurate within 5 minutes. 

Flight Level 

Altitude in hundreds of feet, potential 
DURC (during climb) or DURD 
(during descent) modifier in remarks. 
Potentially UNKN. 

Same, with flight level limit of 51 1 and 
no UNKN indicator. Suggest using 
value of “511” as indicator for “UNKN.” 

Aircraft Type 

Code for aircraft type [6]. 

Class of reporting aircraft within set of 
8 classes. 

Sky Condition 

Cloud cover descriptor, base altitude, 
top, optional “sky clear” indicator, 
optional “in clouds” indicator (IMC 
noted in remarks section). 

Same, but TAIGA limits flight levels of 
tops and bases to 51 1 . Also, multiple 
layers must be reported as separate 
elements, which would be equivalent 
to having multiple ‘/SK’ elements in a 
regular PIREP. 

Flight Visibility and 
Weather 

Visibility reported in statute miles from 
0 to 99. Weather type with intensity 
and optional altitude. 

Same, but no optional altitude 
allowed. Multiple weather types need 
to be reported as separate elements. 

Temperature 

Air temperature using two digits. 

Same, with limits of-60°C and 67°C. 

Wind Vector 

Wind direction and speed. 

Same elements, but direction is one of 
16 major compass rose directions and 
wind speed limited to 255 knots. 

Turbulence 

Intensity, duration, type (CAT or 
CHOP), and altitude of turbulence 
event. 

Range of intensity (e.g., LGT-MOD) 
limited to neighboring values (e.g., 
cannot have LGT-SEV). Multiple 
reports in single PIREP need to be 
reported as separate elements. 
Altitude limited to flight level 51 1 and 
below. Cannot encode “ABV” or “BLO” 
indicators. 

Icing 

Intensity, type, and altitude of icing 
event. 

Range of intensity (e.g., LGT-MOD) 
limited to neighboring values (e.g., 
cannot have LGT-SEV). Multiple 
reports in single PIREP need to be 
reported as separate elements. 
Altitude limited to flight level 51 1 and 
below. Cannot encode “ABV” or “BLO” 
indicators. 

Remarks 

Important phenomena and other 
information not within standard TEIs. 

- 
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The aircraft type is much different in this specification than it is in the traditional PIREP. Instead 
of providing an exact aircraft type based on the FAA descriptions of aircraft [6], this approach 
classifies the aircraft into one of eight classes based on size. Initial, informal discussions with 
pilots indicate that this may be reasonable as the primary goal for knowing the aircraft type is to 
know the effect of a particular phenomenon (such as turbulence) on the aircraft. The savings in 
terms of data compactness are tremendous with this approach. To describe an aircraft as 
belonging to one of eight classes takes exactly three data bits. To describe an aircraft textually 
with up to 4 characters would take up to 28 bits, which is nearly an order of magnitude more data 
to be transmitted. As a concrete example, consider a Piper Super Cub. The code for that aircraft 
is “PA 18” which takes 7 bits per character to transmit (28 bits total), but if the class of that 
aircraft is described as “very small,” which might have class value of “1,” it would require only 
3 bits to transmit. 

Now for the weather phenomena of the PIREP. First, Sky Condition is described with the same 
data as a traditional PIREP with the limitation on the flight level (511 is the maximum). The Sky 
Condition element may contain multiple layers in a traditional PIREP. To achieve that in the 
ASN.l encoding, multiple Sky Condition elements would need to be included, one for each 
reported layer. 

Flight visibility and weather are completely encoded in the ASN.l scheme. The only difference, 
again, is that multiple phenomena need to be included as additional “WX” elements. 
Temperature is properly encoded as well, with the limitation that temperatures must lie between 
-60°C and 67°C. This limitation allows for encoding the temperature in seven bits because the 
range is 127 degrees. 

The wind vector element is correctly encoded with a slight loss in accuracy. In a traditional 
PIREP, the direction is encoded to the nearest 10 degrees, but in the ASN.l scheme, the nearest 
of the 16 major compass rose directions is used. Thus, to translate between the two, the nearest 
compass rose direction to the provided PIREP value must be determined. This results in a 
maximum of 10 degrees of error, with an average error of just 5.6 degrees. When discussing 
wind directions, which are already somewhat uncertain, this error seems like it should be 
tolerable for aviation purposes. Pilots, in general, would like to know the basic direction of the 
wind, but high precision is not of great concern. By limiting to the 16 compass rose directions, 
the wind direction can be encoded in 4 bits, versus the 6 bits it would take to encode the 36 
10-degree values normally used in PIREP reporting. This is a 50-percent savings in transmission 
cost for this particular datum. 

Turbulence is mostly correctly encoded, but is again limited to altitudes below FL511. Also, 
there is no mechanism to indicate “ABV” or “BLO” when discussing altitude ranges. This can be 
overcome by using extreme values as indicators. For example, turbulence from FL020 and below 
can be indicated with a range from FL000 to FL020. The only other limitation in encoding a 
turbulence element is that ranges of intensity must be composed of only neighboring values. For 
instance, a range of light to moderate is acceptable, but the ASN. 1 specification cannot encode a 
range of light to severe. This would be a rare event and would likely be well-served by using the 
more intense value anyway. The icing element has the same limitations as the turbulence element 
and no other limitations. 


14 



The remarks section can encode all values described in the FAA standard [5]. Specifically, it can 
handle low-level wind shear, funnel clouds, thunderstorms, lightning, electric discharge, clouds, 
and plain language description of other phenomena. As a rule, implementors of this system 
should be aware of the high cost of remarks that may have little value to pilots. Sending plain 
language messages should be a last resort as they will be the most costly messages and will 
quickly overwhelm the compression savings gained elsewhere in the encoding scheme. The 
important part for this discussion, however, is that remarks can always be sent as the original 
“RM” string whenever needed and can encode the important events (LLWS, FC, etc.) when 
needed. 

4.4 ASN.1 METAR Data 

The limitations in encoding standard METAR messages are similar to those seen in the PIREP 
encoding. It is hoped that these limitations are minor and will not have a significant effect on the 
utility of the messages. The differences include directionality limited to 16 compass rose 
directions, time accurate within 10 minutes, and a few visibility values being unencodable (2 1/2 
SM, for example). The details of the differences are provided in Table 4. 

4.5 ASN.1 Description of Other Data 

There are other message types available that encode some less standardized data elements. 
For example, this message schema can send image data when necessary (see 
“ImageMessageDefinition” in the Section A. 5). An “Emergency” message (Section A. 6) can also 
be sent that simply includes a text string along with an issue time and an optional end time for 
the emergency. 

A route message (Section A. 7) is also defined such that general information about recommended 
routes can be broadcast. This utility lets pilots in a given area, flying between locations with 
relatively high operation counts, know the current recommended route as determined by the 
service provider. This message type is based on the FAA’s route advisory mechanism that 
controls flows through and around congested or capacity-limited areas [11]. It provides a reason 
for the route, the affected facilities, flights that should be included or excluded, and a set of 
routes (in the form of open polygons in this schema). 

Weather polygons may also be described in this schema through the WeatherPolygon message 
(Section A. 8). This message type provides for the times associated with a weather polygon (valid 
times and forecast times as appropriate) and includes a text string for remarks, the lat-lon points 
describing the polygon, and some other optional elements. This could be useful in describing 
forecasts from, say, the Alaska Aviation Weather Unit (icing, turbulence, IFR/VFR conditions), 
volcanic ash activity, observed precipitation, and any other general phenomena affecting (or 
planned to affect) a defined area. 
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TABLE 4. COMPARISON OF METAR ENCODINGS 


Element 

Federal Standard [7] 

Difference in TAIGA Encoding 

Type 

METAR or SPECI 

- 

Station ID 

4-letter code 

Same, but limited to AK 

Date and Time 

2-digit date, hours, minutes 

Day of week, time accurate within 5 
minutes 

Report Modifier 

AUTO or COR or none 

- 

Wind 

Direction within 10 degrees, speed, 
gust, variability. 

Same elements, but direction is one of 
16 major compass rose directions and 
wind speed limited to 255 knots. 

Visibility 

Fractional and/or integer values, “less 
than” allowed. 

Strictly fractional or integer (e.g., 

2 1/2 SM is impossible, largest value 
is 15, “less than” not allowed. 

Runway Visual Range 

Runway number, runway position, 
lowest value, highest value, 
“plus/minus” modifiers. 

- 

Present Weather 

Up to three groups, which each may 
include intensity/proximity, descriptor, 
and phenomenon. 

One group, otherwise same. TAIGA 
organizes combinations of descriptor 
and phenomenon into a 
comprehensive enumerated list. This 
list is believed to be complete, but 
requires verification. 

Sky Condition 

Automated stations report up to three 
layers. Each layer is either sky cover 
amount and height; vertical visibility; 
or clear. 

Same, but TAIGA does not distinguish 
between SKC and CLR (manual 
versus automated stations). 

Temperature and Dew 
Point 

Two measures in degrees Celsius 
rounded to nearest integer. 

Same, with limits of-60°C and 67°C. 

Altimeter 

Four digits representing tens, units, 
tenths, and hundredths of inches of 
mercury. 

- 

Remarks 

Several potential fields related to 
more detailed or important data not 
covered in fields within the main body. 
Rather than list all the dozens of 
potential fields here, the reader is 
referred to the appropriate METAR 
documentation [7] and just the fields 
that have been encoded in this ASN.1 
scheme are provided. Note that any 
field may be encoded, but with each 
added field, there is additional coding 
and data transmission overhead for 
all METAR data. For each field that is 
potentially encoded, there must be a 
bit transmitted with every METAR that 
indicates if that field is present. 

Peak wind, wind shift, variable 
visibility, sector visibility, hourly 
temperatures, sea level pressure, and 
a maintenance flag are all currently 
encoded. Hourly temperatures are 
rounded to nearest degree. 
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Weather cameras are of particular interest to Alaskan pilots. The FAA’s weather camera project 
produces live or near-live images of various important and/or remote locations of interest to 
pilots in Alaska. The WxCam message (Section A. 9) in this schema allows for a synthesized 
description of the weather cam images, not the images themselves. The synthesized information 
could include visibility and cloud cover height. In the future, other items may be added. These 
data could be generated automatically based on the images themselves, or input manually by 
humans processing the images subjectively. These data could prove useful to pilots without 
access to the Internet to fetch these images themselves. 

Finally, messages that might be used for system maintenance or testing can also be encoded 
(Section A. 10). These might include data or code for updating clients that are active in the field. 
Likely, the first use of this message type would be to send test messages to clients. 

5. Concluding Remarks 

The specification of aviation-related data into an Abstract Syntax Notation One format allows for 
efficient and standardized encodings. These encodings are ideal for the transmission of data, 
especially in throughput-limited scenarios. This work demonstrates the potential for using such a 
specification and subsequent encoding to reduce transmitted file sizes by up to 80 percent in the 
case of PIREPs with similar reductions for other data types. These results open the possibility of 
economically using traditionally expensive communication channels like satellite systems for 
increasing the situational awareness of pilots in remote locations. These pilots may not have 
access to any other means of infonnation gathering at various points in their journey, so any 
additional data could prove useful (even vital), aiding pilots in making more informed decisions. 
The specification presented here will hopefully enter operational testing in Alaska. 
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Appendix A 

ASN.1 Source Files 


This appendix provides copies of the ASN.l source files described earlier in this document. 
These files are provided for reference purposes only and are current only at the time of 
publication. For the most recent versions of the ASN.l source files, interested readers should 
contact the author. Each source file is presented on a new page. 


19 



A.1 Overall Message Definition 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAMessageDefinition . asnl 
Joseph Rios, joseph.l.rios@nasa.gov 
Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Tue Nov 26 14:05:40 PST 2013 


TAIGAMessageDefinition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 


EXPORTS ALL; 

IMPORTS Pirep, AircraftType 

FROM 

PirepMessageDefinition 

Image 

FROM 

ImageMessageDef intion 

System 

FROM 

SystemMessageDefinition 

WeatherPolygon 

FROM 

WxPolyDefinition 

Emergency 

FROM 

Emer gencyMe ssageDef ini t i on 

Met ar 

FROM 

MetarMessageDef inition 

RouteMessage 

FROM 

RouteMessageDef inition 

WxCam 

FROM 

WxCamMes s ageDefinition 

TenMinut eTi cks , Day, Time 

FROM 

CommonTypeDef inition ; 


TAIGAMessage 

A message consists of a time, a day, 
and a payload. Each part 
of the payload may vary in type . 


TAIGAMessage ::= SEQUENCE { 

ref erence -time Time, 

day Day , 

payload - sequence SEQUENCE (SIZE (0 . . 3 , . . . ) ) OF Payload 

> 


-- Keep the choices to a power of 
-- 8 choices seem good? 

Payload : : = CHOICE { 


wxcam 
syt em 
emergency 
image 
pirep 
met ar 
wxpoly 
route 

> 


PayloadWxCam , 
PayloadSystem , 
PayloadEmergency 
Payloadlmage , 
PayloadPirep , 
PayloadMetar , 
PayloadWxPoly , 
PayloadRoute 


2 ? 


(SIZE (0 . . 31) ) OF WxCam 


PayloadWxCam 

PayloadSystem 


Payloadlmage 


: : = SEQUENCE 
: : = SEQUENCE 
: : = SEQUENCE 
: : = SEQUENCE 


(SIZE (0 . . 3) ) 
(SIZE (0 . . 3) ) 
(SIZE (0 . . 3) ) 


OF System 
OF Emergency 
OF Image 


PayloadEmergency 
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PayloadPirep 

PayloadMetar 

PayloadWxPoly 

PayloadRoute 

END 


::= SEQUENCE ( 
::= SEQUENCE ( 
::= SEQUENCE ( 
::= SEQUENCE ( 


SIZE 

(0. 

.31)) 

OF 

SIZE 

(0. 

.31)) 

OF 

SIZE 

(0. 

. 15)) 

OF 

SIZE 

(0. 

.3)) 

OF 


Pirep 

Metar 

WeatherPolygon 

RouteMessage 
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A.2 Common Data Elements 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAImageDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Wed Nov 27 09:54:51 PST 2013 


CommonTypeDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 
EXPORTS ALL; 


-- A polygon in this system will have at most 63 points. 

-- If more points are needed, then an additional Polygon 
-- should be created. Note that there are no restrictions 
-- on the concavity /convexity of the polygons. If a shape 
-- requires a rounded edge, then that shape would need to 
-- be approximated with one of these Polygons. 

Polygon ::= SEQUENCE (SIZE (LongPoly)) OF GeohashString 

LongPoly ::= INTEGER (0 .. 63) 


-- A GeohashString encodes a single point (lat/lon pair). 

-- For a description of how geoahsing works and examples, please see: 

-- http://en.wikipedia.org/wiki/Geohash 
-- http : / / wiki . xkcd . com/geohashing/Main_Page 
-- http : // openlocation . org/geohash/geohash-js/ 

-- In a nutshell, geohashing works by iteratively bisecting the globe, 
-- alternating between vertical and horizontal cuts. Depending on 
-- which side of each cut the point under consideration falls, you 
-- encode a 0 or 1 . As you string more of these together , you get 
-- improving resolution on the point. For every 5 bits that are 
-- encoded, you map that 5-bit string to one of 32 letters and then 
-- encode groups of those letters toegether to ultimately describe the 
-- point. For this project we’ve chosen to encode either 4, 5, or 7 
-- letters for resolutions of 20km, 2.4km, or 0.076km respectively. 

-- Note that these are the maximum errors that occur at the equator. 

-- These errors decrease as you approach the poles. 

GeohashString ::= 

I A5Str ing ( FROM (" 0 123456789 bcdef ghj kmnpqr stuvwxyz ") ) (SIZE (4 I 5 I 7 ) ) 
GeohashStr ingHigh ::= 

GeohashString (SIZE (7)) -- +/- 0.076km error at the equator 

GeohashStr ingMed ::= 

GeohashString (SIZE (5)) -- +/- 2.4km error at the equator 

GeohashStr ingLow ::= 

GeohashString (SIZE (4)) -- +/- 20km error at the equator 


-- Time will be assumed to be UTC in all messages within 
-- this system. These two integers should be more compact 
-- than a formal UTCTime data element. 

Time : : = SEQUENCE { 

hour INTEGER (0 . . 23) , 
minute INTEGER(0. .59) 

> 


-- These are used to act as a positive offset to a provided 
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-- Time instance. There are only 144 ten-minute timesteps 
-- in 24 hours . 

TenMinuteTicks ::= INTEGER (0 .. 144) 

-- All practical commercial and general aviation takes place 
-- below 51,100 feet, so this limit seems reasonable. In 
-- aviation, flight levels are commonly described using the 
-- alt itude /100 . So "flight level 210" corresponds to an 
-- altitude of 21,000 feet. 

FlightLevel ::= INTEGER ( 0 .. 5 1 1 ) 

-- This will be used frequently in many contexts. 

Alt itudeLe velRange ::= SEQUENCE { 
baseAltitude FlightLevel, 

ce il ingAlt itude FlightLevel 

> 

-- These are based on the standard cloud coverage values used 
-- in METARs and PIREPs. 

SkyCloudCover ::= ENUMERATED { 
none , 
bkn , 
few , 
ovc , 
set , 
ske , 

not - supplied , 
vv 

> 


-- This is used in combination with the Time element 
-- in lieu of a proper date in order to take care the 
-- most common time interpretation issues (times near 
-- midnight probably). 

Day ::= ENUMERATED { 

Sunday , 
monday , 
tuesday , 

Wednesday , 
thursday , 
friday , 

Saturday 

> 

-- We could use an integer between 0 and 359 , but this 
-- encoding uses fewer bits and provides an appropriate 
-- resolution for describing wind direction since such 
-- measurements are not extremely accurate in the first 
-- place and pilots do not require high precision to make 
-- informed decisions. 152 degrees versus 148 degrees 
-- will not make a difference to most pilots. 
WindDirection ::= ENUMERATED { 
n , 
e , 
w , 
s , 


23 


ne , 
nw , 
se , 
sw , 
nne , 
nnw , 
sse , 
ssw , 
wsw , 
ese , 
ene , 
wnw 

> 


-- If we want or need 
-- Wind Direction , we 
-- not used anywhere? 
WindDirectionDegrees 


a precise value (within 1 degree) for 
can use this. Currently (5/1/2014) 

: = INTEGER (0 . . 359) 


-- Wind speeds 

will not reach 

255 . If they 

did 

-- ever happen 

to surpass that 

value , cutt in 

g it 

-- off at 255 

will be plenty enough warning 

that 

-- there probably shouldn’t be 

any flying go 

ing 

WindSpeed : : = 

INTEGER (0 . .255) 



WindReport 

: : = SEQUENCE { 



direct ion 

WindDirection 

> 


speed 

WindSpeed 




Dir e ct i onOf Mo vement ::= SEQUENCE { 
f romDirection WindDirection , 
toDirection WindDirection 

> 


Station Identifier 


St 


The station identi 
of the possible st 
for AK and would b 
at i onldent if i er ::= 
padk , 
pafm , 
pakp , 
pane , 
palh , 
pamr , 
pani , 
pant , 
panv , 
pare , 


fier should 
ations? The 
e extremely 
ENUMERATED 


ultimately be an enumeration 
list is quite long (150+) 
long for the CONUS. 

{ 
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paak , 
pabr , 
paba , 
pabe , 
pabt , 
palv , 
pabv , 
pabl , 
patw , 
palu , 
paeh , 
pacz , 
pari , 
pair , 
pajc , 
pacr , 
pacd , 
pacv , 
pasc , 
pade , 
pabi , 
padl , 
paeg , 
pasy , 
paii , 
paei , 
pael , 
paed , 
paem , 
pazk , 
paf a , 
paf k , 
pafb , 
pfyu , 
pafn , 
pagb , 
paga , 
pagm , 
pagl , 
pagk , 
pags , 
pahn , 
pahz , 
pahv , 
paho , 
paoh , 
pahp , 
pahs , 
pahy , 
pail , 
paim , 
pajn , 
paf e , 
pakv , 
paen , 
pakt , 
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pakn , 
kqrc , 
pavl , 
pakw , 
padq , 
paot , 
pakk , 
paku , 
paml , 
pamx , 
pamc , 
pain , 
pamy , 
pamm , 
pamd , 
pamh , 
pabn , 
pann , 
paom , 
paec , 
paor , 
pawn , 
paqt , 
poli , 
paaq , 
paxk , 

P a Pg . 
papo , 
ppiz , 
paap , 
palj , 
papc , 
paph , 
pato , 
papr , 
paud , 
papt , 
pard , 
pasm , 
pasd , 
pasa , 
pask , 
paso , 
pawd , 
pash , 
pasi , 

pagy . 

pasw , 
padt , 
pasl , 
palk , 
pasx , 
pasv , 
papb , 
pasn , 
paer , 
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paj v , 
pasp , 
patk , 
pata , 
patl , 
pate , 
patg , 
paum , 
paun , 
padu , 
pavd , 
pavw , 
pawi , 
paws , 
pawr , 
pauo , 
paiz , 
pawg , 
paya , 


> 


-- This is a range of 127 and will be encoded with 7 bits using 
-- the PER. This range covers all practical Celcius values for 
-- aviation purposes. If a temperture somehow needs to fall out 
-- of this range, it would be effectively the same as providing 
-- the extreme values . For example if there was a need to report 
-- a temperature of 72 degrees celcius , that is for all practical 
-- purposes the same as reporting 67 degrees celcius, i.e. it is 
-- pretty dang hot. Likewise for lower temps, if we needed to 
-- report -70 degrees celcius , it would be just as effective to 
-- report -60 for aviation purposes. 

Temperature ::= INTEGER ( -60 .. 67) 

END 
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A. 3 METAR Messages 


TAIGAMetarDefinition . asnl 
Joseph Rios, joseph.l.rios@nasa.gov 
Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 
-- Created: Mon Dec 02 15:41:18 PST 2013 

MetarMessageDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 

EXPORTS ALL; 

IMPORTS Temperature , WindReport , TenMinut eTi cks , 

WindDirection , SkyCloudCover , St at ionldent if ier , 
WindSpeed FROM CommonTypeDef inition 
PirepWeatherMetarCode FROM PirepMessageDef inition ; 


-- File name: 

-- Author : 

-- Organization 


METAR 

The formatting of this message 
type follows the standard formatting 
of METARs as described in: 

Surface Weather Observations and 
Reports by Dept of Commerce / NOAA 


Metar 


SEQUENCE { 


metarType 

MetarType , 

station 

St at ionldent if ier , 

time 

TenMinut eTi cks , -- o 

isAuto 

BOOLEAN , 

isCorrected 

BOOLEAN , 

wind 

MetarWind , 

visibility 

MetarVisibility , 

rvr 

MetarRvr OPTIONAL, 

weather 

MetarWeather OPTIONAL 

sky 

Met ar SkyCondit i ons , 

temperature 

MetarTemperature , 

altimeter 

Met ar Alt imet er , 

remarks 

MetarRemarks OPTIONAL 


offset from the header time 


Metar Type 


MetarType ::= ENUMERATED { 
metar , 
speci 

> 
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Wind 


MetarWind ::= SEQUENCE { 

windReport WindReport , 

gust WindSpeed OPTIONAL, 

variable MetarVariableWind OPTIONAL 

> 

MetarVariableWind ::= SEQUENCE { 
directionA WindDirection , 
direction!? WindDirection 


Visibility 


-- If the visibility is fractional, then the value 
-- member will represent binary fractions, otherwise, 
-- it will represent a standard integer from 0 to 15. 
-- Binary fraction place values would be: 

-- 0.5 0.25 0.125 0.0625 

-- So, the value of 3/4 would be represented 
-- by 1100 (Integer value 12). 

MetarVisibility ::= SEQUENCE { 
isFractional BOOLEAN, 
value INTEGER (0 . .15) 

> 


Runway Visual Range 


MetarRvr : : = 
runway 
position 
range 


SEQUENCE { 

INTEGER (1 . . 36) , 
MetarRunwayPosition , 

Me t ar Runway Vi sual Range 


> 

MetarRunwayPosition ::= ENUMERATED { 
left , 
right , 
mid , 
none 

> 

Met arRunway Vi sualRange ::= SEQUENCE { 
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value A 
valueB 


MetarRvrValue , 
MetarRvrValue OPTIONAL 


> 

MetarRvrValue ::= SEQUENCE { 

modifier MetarRvrValueModif ier OPTIONAL, 
value MetarRvrValuelnt 

> 

MetarRvrValueModif ier ::= ENUMERATED { 
m , 

P 

> 


-- This type of description for RVR can’t be handled 
-- well in ASN . 1 . Use enumeration instead. 
--MetarRvrValuelnt ::= INTEGER (600 I 700 I 800 I 900 I 
1000 I 1200 | 1400 | 1600 I 1800 I 2000 I 2200 I 2400 I 2600 I 
2800 | 3000 | 3500 I 4000 I 4500 I 5000) 

MetarRvrValuelnt ::= ENUMERATED { 
e600 , 
e700 , 
e800 , 
e900 , 
elOOO , 
el200 , 
e 1400 , 
el600 , 
el800 , 
e2000 , 
e2200 , 
e2400 , 
e2600 , 
e2800 , 
e3000 , 
e3500 , 
e4000 , 
e4500 , 
e5000 


Weather 


MetarWeather ::= SEQUENCE { 

intensityVicinity Met arWx Int ens ity Vi c inity , 
weather PirepWeatherMetarCode 

> 

MetarWxIntensityVicinity ::= ENUMERATED { 
plus , 
minus , 
vicinity , 
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none 


> 


Sky Conditions 


Met arSkyCondit ions ::= SEQUENCE (SIZE(0..3)) OF SkyCondit ionLayer 

SkyCondit ionLayer ::= CHOICE { 

regular SkyCondit ionLayerRegular , 
vertical SkyConditionLayerVertical , 
clear BOOLEAN 

> 

SkyCondit i onLayerRegular ::= SEQUENCE { 
skyCloudCover SkyCloudCover , 

cloudCoverHeight CloudCoverHeight 

> 

SkyConditionLayerVertical ::= SEQUENCE { 
cloudCoverHeight CloudCoverHeight 

> 

CloudCoverHeight : := CHOICE { 
upto5000 CcUpto5000, 
uptolOOOO CcUptolOOOO, 
overlOOOO CcOverlOOOO 

> 


-- From FAA METAR documentation: 

-- Table 14-6: Increments of Reportable Values of Sky Cover Height 

-- Range of Heights (feet) Reportable Values (feet) 

-- 5,000 or less To nearest 100 
-- >5,000 but <=10,000 To nearest 500 
-- Above 10,000 To nearest 1,000 

CcUpto5000 ::= INTEGER (0 .. 50) -- Multiply by 1 

CcUptolOOOO ::= INTEGER ( 1 1 .. 20) -- Multiply by 5 

CcOverlOOOO ::= INTEGER ( 1 1 .. 42) -- Multiply by 10 


Temperature 


MetarTemperature : := SEQUENCE { 
temperature Temperature , 
dewPoint Temperature 

> 
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Altimeter 


-- Value is multplied by 100. 
MetarAltimeter ::= INTEGER(0. 

Divide by 100 to 
. 9999) 

Remarks 

-- 

-- 

-- 


HetarRemarks : := SEQUENCE { 

peakWind MetarPeakWind OPTIONAL, 

windShift Met arWindShif t OPTIONAL, 

-- alternateViz MetarVisibility OPTIONAL, 
variableViz MetarVariableVisibility OPTIONAL, 

sectorViz Met ar Se c t orVi s ibi 1 i t y OPTIONAL, 

hourlyTemp MetarTemperature OPTIONAL, 

seaLevelPressure INTEGER ( 0 .. 20 1 ) OPTIONAL, 
maintenance BOOLEAN , 


MetarPeakWind ::= SEQUENCE { 
windReport WindReport , 
time TenMinuteTicks 


MetarWindShift ::= SEQUENCE { 
hour INTEGER (0 . . 23) , 

minute INTEGER(0. .59) , 

hasFropa BOOLEAN 

> 

MetarVariableVisibility ::= SEQUENCE { 
visibilityA MetarVisibility, 
visibilityB MetarVisibility 

> 

Met ar Sect orVi s ibility ::= SEQUENCE { 
direction WindDirection , 
visibility MetarVisibility 

> 

END 


value . 
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A.4 PIREP Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAPirepDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Wed Nov 27 09:51:09 PST 2013 


PirepMessageDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 

EXPORTS Pirep , PirepWeatherMetarCode , PirepSkyCover ; 

IMPORTS GeohashStr ingHigh , FlightLevel , 

AltitudeLevelRange , WindDirection , 

Temperature , WindReport , DirectionOf Movement , 
SkyCloudCover FROM CommonTypeDef init i on ; 


Pilot Weather Report 
(PIREP) 


Pirep : : = SEQUENCE 
isUUA 
isAWC 

f lightLevel 

duringClimb 

duringDescent 

aircraft 

t imeOf f set 

position 

element Sequence 


{ 

BOOLEAN , 

BOOLEAN , 

FlightLevel , 

BOOLEAN , 

BOOLEAN , 

AircraftType , 

INTEGER (0 . . 31) , 
GeohashStr ingHigh , 
SEQUENCE (SIZE (0 . . 31) ) 


> 


OF PirepElement 


AircraftType ::= ENUMERATED { 
tiny , 

very - small , 
small , 
medium , 
medium -large , 
large , 
heavy , 
j umbo 

> 


PirepElement : : 
turbulence 
temperature 
icing 
sky 
wind 
weather 
remark 
reserved 

> 


CHOICE { 

PirepElementTurbulence , 
PirepElementTemperature , 
PirepElementlcing , 
PirepElement SkyCondit ion , 
PirepElementWindVector , 
PirepElementWeather , 
PirepElementRemark , 
PirepElementReserved 
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Turbulence Element 
/TB 


PirepElementTurbulence ::= SEQUENCE { 

intensity PirepTurbulencelntensity , 

cat BOOLEAN , 

chop BOOLEAN , 

duration P ir epTurbulenceDur at ion , 


> 


flightLevel Alt itudeLevelRange OPTIONAL 


PirepTurbulencelntensity ::= ENUMERATED { 
Igt . 

lgt -mod , 
mod , 

mod - sev , 
sev , 

sev -extrm , 
extrm , 
neg 

> 

PirepTurbulenceDuration ::= ENUMERATED { 
cont , 
ocnl , 
intmt , 
none 

> 


Air Temperature Element 
/TA 


PirepElementTemperature ::= SEQUENCE { 
temperature Temperature 

> 


Icing Element 
/IC 


Pir epElement I c ing ::= SEQUENCE { 

intensity Pireplcinglntensity , 

type PirepIcingType , 

flightLevel Alt itudeLe ve IRange OPTIONAL 

> 

Pireplcinglntensity ::= ENUMERATED { 


ENUMERATED { 


trace , 
trace - lgt , 

Igt , 

lgt -mod , 
mod , 

mod - sev , 
sev , 
neg 

> 

Pir ep I c ingType ::= 
none , 
clear , 
rime , 
mixed 

> 


-- 

Sky 

/SK 

Condition Element 

Pir epElement SkyCondi t i on ::= SEQUENCE { 


skyClearAbove 

BOOLEAN , 


inCloudsIMC 

BOOLEAN , 


cloudCoverRange 

PirepSkyCloudCoverRange , 


f lightLevel 

AltitudeLevelRange 

> 



PirepSkyCloudCoverR 

ange ::= SEQUENCE { 


cloudCover A 

PirepSkyCloudCover , 


cloudCoverB 

PirepSkyCloudCover 

> 



PirepSkyCloudCover 

: := SkyCloudCover 

-- 

Wind 

Vector Element 

-- 

/WV 

-- 

PirepElementWindVector ::= WindReport 

-- 

Weather Element 

-- 

/WX 

-- 

— 


— 


PirepElementWeather ::= SEQUENCE { 

visibility P i repWe athe rV i sibil it y 
phenomenon PirepWeatherPhenomenon 


> 


OPTIONAL , 
OPTIONAL 
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PirepWeatherVisibility 


INTEGER (0 . . 127) 


PirepWeatherPhenomenon ::= SEQUENCE{ 

intensity PirepWeatherlntensity , 
metar-code PirepWeatherMetarCode 

> 

PirepWeatherlntensity ::= ENUMERATED { 
plus , 
minus , 
none 

> 

PirepWeatherMetarCode ::= ENUMERATED { 


drsn , 

-- 

Drifting snow 

blsn , 

-- 

Blowing snow 

drdu , 

-- 

Drifting dust 

drsa , 

-- 

Drifting sand 

dz , 

-- 

Drizzle 

fzdz , 

-- 

Freezing drizzle 

du , 

-- 

Dust 

bldu , 

-- 

Blowing dust 

ds , 

-- 

Dust st orm 

fg . 

-- 

Fog 

fzfg > 

-- 

Freezing fog 

f zra , 

-- 

Freezing rain 

f c , 

-- 

Funnel cloud 

gr . 

-- 

Hail (1/4" diameter or more) 

shgr , 

-- 

Hail Shower 

hz , 

-- 

Haze 

ic , 

-- 

Ice crystals 

Pi > 

-- 

Ice pellets 

shpl , 

-- 

Ice pellet showers 

br , 

-- 

Mist (visibility 5/8sm or more) 

bcfg , 

-- 

Patchy fog 

prfg > 

-- 

Patchy fog on part of airport 

ra , 

-- 

Rain 

shra , 

-- 

Showers 

sa , 

-- 

Sand 

blsa , 

-- 

Blowing sand 

ss , 

-- 

Sandstorms 

mifg , 

-- 

Shallow fog 

shgs , 

-- 

Small hail/snow pellets showers 

gs , 

-- 

Small hail/show pellets 

fu , 

-- 

Smoke 

sg » 

-- 

Snow grains 

sn , 

-- 

Snow 

shsn , 

-- 

Snow showers 

py > 

-- 

Spray 

sq , 

-- 

Squalls 

ts , 

-- 

Thunderstorm 


-- +fc, Tornado /Wat er spout can’t be represented in ASN . 1 , 
but can be encoded using intensity ’+’ and fc 
up, -- Unknown precipitation 

va , -- Volcanic ash 

po , -- Well -developed dust/sand whrils 


36 


ime , 

-- Instrument 

vmc , 

-- Visual met 

clr , 

-- Clear 

tsra , 


tssn , 


tspl , 


tsgs , 


tsgr , 



Remark Element 
/RM 


PirepElementRemark ::= SEQUENCE { 
text UTF8Str ing OPTIONAL, 

llws PirepLowLevelWindShear OPTIONAL, 

fc PirepFunnelCloud OPTIONAL, 

ts PirepThunderstorm OPTIONAL, 

lightning PirepLightning OPTIONAL, 
discharge AltitudeLevelRange OPTIONAL, 
clouds UTF8Str ing OPTIONAL , 


> 


PirepLowLevelWindShear 
plus 
minus 
altitude 
text 


:= SEQUENCE { 

BOOLEAN , 

BOOLEAN , 

AltitudeLevelRange OPTIONAL, 
UTF8Str ing OPTIONAL 


> 


PirepFunnelCloud ::= SEQUENCE { 

type PirepFunnelCloudType , 

direction Dir e ct ionOf Mo vement OPTIONAL 

> 


PirepFunnelCloudType ::= ENUMERATED { 
tornado , 
waterspout , 
f unnelcloud 

> 


PirepThunderstorm ::= SEQUENCE { 

coverage PirepThunderstormCoverage , 

description P ir epThunder st ormDe s cr ipt ion OPTIONAL, 
direction Dir e ct ionOf Mo vement OPTIONAL 


PirepThunderstormCoverage ::= ENUMERATED { 
isol , 
few , 
set , 
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nmr s 


> 


Pir epThunder s t ormDes cr ipt i on ::= ENUMERATED { 
In , 

bknln , 
sldln 

> 


PirepLightning 

frequency 

Itgic 

ltgcc 

Itgcg 

ltgca 

> 


: : = SEQUENCE { 
PirepLightningFrequency , 
BOOLEAN OPTIONAL, 

BOOLEAN OPTIONAL, 

BOOLEAN OPTIONAL, 

BOOLEAN OPTIONAL 


PirepLightningFrequency ::= ENUMERATED { 
ocnl , 
f rq , 
cons , 

not -reported 

> 


Reserved Element 


PirepElementReserved : := SEQUENCE { 

> 

END 


38 


A.5 Image Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAImageDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Wed Nov 27 12:48:56 PST 2013 


ImageMessageDef intion DEFINITIONS AUTOMATIC TAGS ::= BEGIN 
EXPORTS ALL; 

IMPORTS WindDirect ionDegrees , 

GeohashStr ingLow , 

GeohashStr ingMed , 

GeohashStr ingHigh FROM CommonTypeDef init ion ; 


Image 

If bandwidth and ecomonics allow, 
this message type will provide a 
means to transmit an image as a 
string of bytes (OCTET STRING) 


Image : : = SEQUENCE { 

description UTF8String , 
image 
location 
direct ion 


OCTET STRING , 

ImageLo cat ion OPTIONAL, 
WindDire ct ionDegrees OPTIONAL 


> 


ImageLocat ion : : 
hiFidelityPt 
mdF ide 1 ityPt 
loFidelityPt 

> 


= CHOICE { 
GeohashStr ingHigh , 
GeohashStr ingMed , 
GeohashStringLow 


END 
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A. 6 Emergency Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAEmer gencyDef init i on . asnl 
Joseph Rios, joseph.l.rios@nasa.gov 
Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Mon Dec 02 15:11:47 PST 2013 


Emer gencyMe ssageDef ini t i on DEFINITIONS AUTOMATIC TAGS ::= BEGIN 
EXPORTS Emergency ; 

IMPORTS TenMinut eTi cks FROM CommonTypeDef init i on ; 


Emergency 


This message type could be used 
for urgent of emergency messages 
that do not fit any other category. 


Emergency : : = 
message 
issueT ime 
endingTime 


SEQUENCE { 
UTF8String , 
TenMinut eT i cks 
TenMinuteTicks 


OPTIONAL , 


> 

END 
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A. 7 Route Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGARouteDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Mon Mar 03 11:26:37 PST 2014 


RouteMessageDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 
EXPORTS RouteHessage ; 

IMPORTS Alt itudeLevelRange , St at ionldent if ier , Polygon FROM CommonTypeDef inition 


Route 

If there were a need to transmit 
a route definition to an aircraft 
or group of aircraft , one could do 
so with this message type. This is 
roughly modeled upon the way the FAA 
defines reroute advisories, but does 
not have an immediate , current 
analog in Alaska. 


RouteMessage ::= SEQUENCE { 


> 


type 

reason 

comment 

timelnclusion 

typelnclusion 

depFac il it ie s 

arrFac il it ie s 

alt Indus ion 

typeExclusion 

altExclusion 

route 


RouteType OPTIONAL, 

RouteReason OPTIONAL, 

UTF8Str ing OPTIONAL , 

Rout eTimeType OPTIONAL, 

RouteAircraf tType OPTIONAL, 

SEQUENCE (SIZE (0..7)) OF St at i onldent if ier 
SEQUENCE (SIZE (0..7)) OF St at i onldent if ier 
Alt itudeLevelRange OPTIONAL, 

RouteAircraf tType OPTIONAL, 

Alt itudeLevelRange OPTIONAL, 

SEQUENCE (SIZE (0..3)) OF Polygon 


OPTIONAL , 
OPTIONAL , 


RouteType ::= ENUMERATED { 
recomended , 
required , 
informational , 
other 

> 


RouteReason ::= ENUMERATED { 
weather , 
equipment , 
military , 
other 

> 


RouteTimeType ::= ENUMERATED { 
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ENUMERATED { 


etd , 
eta , 
f ca , 
other 

> 

Route Air craf tType ::= 
all - air cr af t 


> 

END 
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A.8 Weather Polygon Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGAWxPolyDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Mon Dec 02 13:41:28 PST 2013 


WxPolyDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 


EXPORTS WeatherPolygon ; 

IMPORTS GeohashPoint HighFidel it y , GeohashPoint LowFide 1 ity , 
GeohashPoint MedFide 1 ity , TenMinut eTi cks , 
AltitudeLevelRange , WindDirection , 

Polygon FROM CommonTypeDef inition ; 


Weather Polygons 

This message type allows for the 
description of various weather 
polygons . 


WeatherPolygon ::= 
type 
title 
polygon 
validT ime 
val idTimeEnd 
f or e cast Time 
f lightLevel 
direct ion 
remarks 

> 


SEQUENCE -C 
WeatherPolygonType , 
UTF8String , 

Polygon , 

TenMinut eTi cks , 

TenMinut eTi cks OPTIONAL, 
TenMinut eTi cks OPTIONAL, 
AltitudeLevelRange OPTIONAL, 
WindDirection OPTIONAL, 
UTF8Str ing OPTIONAL 


-- These types are not codified anywhere else, but they represent 
-- our best guess at the types of polygons that will be of interest 
-- to users of this system. Note that this ENUMERATED type is 
-- extensible and that any polygon can be described using the ’generic’ 
-- type with an appropriate remark in the WeatherPolygon data. 
WeatherPolygonType ::= ENUMERATED { 
generic , 
turbulence , 
icing , 

precipitation , 
volcanic -ash , 
visibility , 
downslope -winds , 


> 

END 
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A. 9 Weather Cam Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAI GAWxCamDef inition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Tue Apr 01 11:40:39 PDT 2014 


WxCamMessageDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 


EXPORTS ALL; 

IMPORTS WindDirection , GeohashStr ingHigh 
FROM CommonTypeDef init i on 
Met arVi s ibil ity , CloudCoverHeight 
FROM MetarMessageDef inition ; 


Weather Cameras 


This message type allows for the 
description of data that might 
be available from weather cameras. 


WxCam : : = 
id 


SEQUENCE { 

WxCamldent if i er OPTIONAL, 


position 
direct ion 
visibility 


GeohashStr ingHigh , 
WindDirection , 
MetarVisibility , 


ceiling CloudCoverHeight OPTIONAL 

comment UTF8String OPTIONAL, 


-- make this optional in case 
-- we’re describing a non-standard 
-- location . 

-- the direction of the camera 
-- this may be determined through 
-- analysis of the image . 


> 


-- These are all of the Alaska weather cam stations as of 10 April 2014. 

WxCamldent if ier ::= ENUMERATED { 
akhiok , 
akun - island , 
allakaket , 
ambler , 

anaktuvuk -pass , 
anchor -point , 
anchorage , 
angoon , 
aniak , 
anvik , 

arctic -village , 
atqasuk , 
barrow , 
beaver , 
beluga , 
berners -bay , 
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bethel , 
bettles , 
birchwood , 
black -rapids , 
br adley - lake , 
buckland , 
cape - f anshaw , 
cape-spencer , 
cape -yakataga , 
central , 
chalky it s ik , 
chandalar -shelf , 
chef ornak , 
chevak , 
chickaloon , 
chignik -bay , 
chignik - lagoon , 
chignik - lake , 
chilkat , 
chistochina , 
chit ina , 
darks -point , 
cold -bay , 
coldf oot , 
cooper -landing , 
cordova , 
craig , 

cr ooked - creek , 
deadhorse , 
deering , 
delt a - j unction , 
dillingham , 
dutch -ballyhoo , 
dutch -haystack , 
dutch -ndb , 
eagle , 
edna -bay , 
eek , 
egegik , 
elim , 
emmonak , 
ester -dome , 
false -pass , 
fort -yukon , 
galena , 
gambell , 
golovin , 
grave -point , 
grayling , 
gulkana , 
gustavus , 
gustavus -dock , 
haines , 
hawk - inlet , 
holy - cross , 
homer , 
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honolulu , 

hoonah , 

hooper -bay , 

husl ia , 

hydaburg , 

hyder , 

igiugig , 

iliamna , 

is ab el -pass , 

j ohnstone -point , 

j ohnstone -point -vor , 

kake , 

kalskag , 

kaltag , 

karluk , 

kasaan , 

kas igluk , 

ket chikan , 

kiana , 

king - cove , 

king - salmon , 

kipnuk , 

kivalina , 

klawock , 

knik , 

knob -ridge , 

kodiak , 

kokhanok , 

koliganek , 

kotlik , 

kotzebue , 

koyuk , 

kwethluk , 

kwigillingok , 

lake-cl ark-pass-east 

lake - dark -pass -rco , 

lake -dark - pass - west 

larsen -bay , 

lena -point , 

level -island , 

lime -village , 

livengood , 

manokot ak , 

marshall , 

mcgrath , 

mckinley -north , 

mckinley -park , 

mckinley - south , 

mekoryuk , 

mentasta , 

merrill -pass -high , 
merrill -pass -low , 
metlakatla , 
meyer s - chuck , 
middiet on - island , 
minchumina , 
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minto , 

misty -f j ords , 
moose -pass , 
mountain -village , 
nanwalek , 
napakiak , 
nelson -lagoon , 
nenana , 
new - stuyahok , 
newtok , 
nikiski , 
nikolai , 
noatak , 
nome , 

nondalt on , 
north -slope , 
northway , 
nuiqsut , 
nulato , 
nunapit chuk , 
nyac , 

old-harbor , 
ouzinkie , 
palmer , 

pedersen -hill , 
pedro -bay , 
pelican , 
perryville , 
Petersburg , 
pilot -point , 
platinum , 
point -higgins , 
point -hope , 
point -lay , 
port - alexander , 
port -heiden , 
port -lions , 
portage -creek , 
portage -glacier , 
potato -point , 
punt ilia - lake , 
quinhagak , 
red-dog , 
rohn , 
ruby , 

ruby - airport , 
russian -mission , 
savoonga , 
scammon -bay , 
selawik , 
seward , 
shageluk , 
shaktoolik , 
sheep -mountain , 
shishmaref , 
shungnak , 
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sisters -island , 
sitka , 
skagway , 
skwentna , 
sleetmute , 
soldotna , 
st -marys , 
st -michael , 
st -paul , 
summit , 
tahneta -pass , 
takotna , 
taku - inlet , 
talkeetna , 
tanana , 

t azlina - 1 olsona , 
teller , 

tenakee - springs , 
thompson -pass , 
thorne -bay , 
togiak , 
tok , 

toksook -bay , 
trading -bay , 
tuluksak , 
tuntutuliak , 
uganik -bay , 
unalakleet , 
valdez , 
wainwright , 
wales , 
wasilla , 
white -mountain , 
whittier , 
willow , 
wrangell , 
yakutat , 

yukon -river -bridge , 


> 

END 
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A. 10 System Messages 


-- File name: 

-- Author : 

-- Organization: 


-- Created : 


TAIGASystemDefinition . asnl 

Joseph Rios, joseph.l.rios@nasa.gov 

Aviation Systems Division, 

NASA Ames Research Center , 

Moffett Field, CA 

Thu Feb 13 16:39:35 PST 2014 


SystemMessageDef inition DEFINITIONS AUTOMATIC TAGS ::= BEGIN 
EXPORTS ALL; 


System 

This message type amay be used for 
system updates to software within the -- 
receiving system or testing the 
system . 


System : := SEQUENCE { 
des cr ipt ion 
data 

> 

END 


UTF8String , 
OCTET STRING 
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Appendix B 

Encoding Examples 

This appendix provides concrete encoding examples. The first is a pair of artificial weather 
polygons and the second is a set of real Alaskan METARs. 

B.1 Weather Polygon Example 

Because many weather products for Alaska are only provided in graphical or textual formats and 
not in particularly machine-readable formats, two artificial weather polygons that represent the 
type of data that might be encoded in this scheme have been created. 


B.2 METAR Example 

At the far northern edge of Alaska, there are four METAR stations located relatively close 
together. In an operational TAIGA system, the reports from these four stations might be bundled 
together into a single METAR update for pilots in the vicinity of those weather stations. In this 
example, the METARs for each of those stations are encoded using the ASN. 1 scheme presented 
here. 

Figure B1 summarizes all of the METAR data for the state of Alaska during the 2200Z hour on 
May 7th with an added highlight around the four aforementioned stations in the far north. 
Subsequently, Figure B2 shows an enlarged view of the four stations. To provide a sense of how 
METARs are currently encoded in text format, the text of those four particular METARs is 
shown below (for full interpretation, the reader is directed to NOAA’s manual [7] regarding 
METARs.): 

• PALU 072155Z AUTO 36003KT 10SM CLR M04/M06 A2993 RMK A02 SLP135 
T1041 1060 

• PPIZ 072156Z AUTO 26006KT 10SM CLR M04/M08 A2993 RMK A02 TSNO 
T10381077 SLP137 $ 

• PAWI 072200Z AUTO 1 8008KT 1 OSM BKNO 1 0 BKN034 M03/M06 A2989 RMK A02 
TSNO 

• PABR 072153Z 23010KT 10SM OVC007 M05/M06 A2989 RMK A02 CIG 005 VO 10 
SLP124 T10501061 

They are described in the ASN. 1 specification detailed in Appendix A. Upon doing so, the data 
can be encoded in any of the available ASN.l encoding schemes. For this example, the data was 
encoded using the XML encoding rules (XER) and the unaligned packed encoding rules 
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Figure B1. Graphical METAR data. 



Figure B2. Detail of four METARs in northern Alaska. 
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(uPER). The XER allows for a human-readable format of the data. The uPER allows for a highly 
efficient machine -readable format. 


The resulting XML is provided here in its entirety: 


<TAIGAMessage> 


Creference -time> 


<hour>21</hour> 


<minut e > 50 </ minute > 
</reference-time> 

<day >< wedne sday / ></day > 
<payload- sequence > 


<metar > 

<Met ar > 


<metarType><metar/x/metarType> 

<station><palu/></ station) 

<time>0</time> 

<isAuto><true/x/isAuto> 

<isCorrected><false/x/isCorrected> 

<wind> 

<windReport > 

<direction><n/></ direction) 
<speed>3</ speed) 
</windReport > 

</ wind) 


<isFractional)<false/x/isFractional> 
<value>10</ value) 

</ visibility) 

< sky > 


</ sky) 

< temperature > 

< temper at ure > -4</ temperature > 
<dewPoint>-6</ dewPoint) 

</ temperature) 

<altimeter)2993</altimeter> 

<remarks > 

<hour lyTemp > 

< temperature) -4 </ temperature > 
<dewPoint>-6</ dewPoint) 

</hourlyTemp> 

<seaLevelPres sure) 135 </seaLevelPres sure) 
<maintenance)<false/x/maintenance> 

</ remarks > 


<metarType)<metar/x/metarType> 
<station)<ppiz/></ station) 
<time>0</time> 
<isAuto)<true/x/isAuto> 
<isCorrected)<f alse/></ isCorrected) 
<wind> 

<windReport > 

<direction)<w/></ direction) 
<speed>6</ speed) 



<clear)<true/></ clear) 


</Metar > 
<Met ar > 
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</windReport > 


</ wind> 



<isFractional><f alse/x/isFractional> 
<value>10</ value> 

</ visibility > 

< sky > 


</ sky > 

< temperature > 

< temper at ure >-4</temperature> 
<dewPoint>-8</ dewPoint> 

</ temperature > 

<altimeter>2993</altimeter> 

<remarks > 

Chour lyTemp > 

<temperature>-4</ temper at ure > 
<dewPoint>-8</ dewPoint> 

</hourlyTemp> 

<seaLevelPres sure > 137 </ seaLevelPres sure > 
<maintenance><true/x/maintenance> 

</ remarks > 


<metarType><metar/x/metarType> 

<stationXpawi/x / station> 

<time>l</time> 

<isAuto><true/x/isAuto> 

<isCorrected><false/x/isCorrected> 

<wind> 

<windReport > 

<direction><s/></ direction> 
<speed>8</ speed > 
</windReport > 

</ wind> 


<isFractional><false/x/isFractional> 
<value>10</ value> 

</ visibility > 

< sky > 


<regular > 

<skyCloudCover><bkn/x/skyCloudCover> 

<cloudCoverHeight> 

<upt o5000 > 10 </ upt o5000 > 

</ cloudCoverHeight > 

</ regular > 

<regular > 

<skyCloudCover><bkn/x/skyCloudCover> 

<cloudCoverHeight> 

<upt o5000 >34 </ upt o5000 > 

</ cloudCoverHeight > 

</ regular > 


<clear><true/></ clear> 


</Metar > 
<Met ar > 



</ sky > 
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< temperature > 

<temperature>-3</ temperature > 

<dewPoint>-6</ dewPoint> 

</ temperature > 

<altimeter>2989</altimeter> 

</Metar > 

<Met ar > 

<metarType><metar/x/metarType> 

<station><pabr/></ station> 

<time>0</time> 

<isAutoXfalse/>< / isAuto> 
<isCorrected><false/x/isCorrected> 

<wind> 

<windReport > 

<direction><sw/></ direction> 
<speed>10</speed> 

</windReport > 

</ wind> 

<visibility> 

<isFractionalxfalse/x/isFractional> 
<value>10</ value> 

</ visibility > 

< sky > 

<regular > 

<skyCloudCoverXovc/x/skyCloudCover> 
<cloudCoverHe ight > 

<upt o5000 >7</upto5000> 

</ cloudCoverHeight > 

</ regular > 

</ sky > 

< t emper at ur e > 

<temperature>-5</ temperature > 

<dewPoint>-6</ dewPoint> 

</ temperature > 

<altimeter>2989</altimeter> 

<remarks > 

<hour lyTemp > 

<temperature> -5 </ temper ature > 
<dewPoint>-6</ dewPoint> 

</hourlyTemp> 

<seaLevelPressure>124</seaLevelPressure> 

<maintenancexfalse/x/maintenance> 

</ remarks > 

</Metar > 

</ metar > 

</payload- sequence > 

</TAIGAMessage> 

Note that this is quite verbose and would not be appropriate for broadcasting over a 
throughput-limited communication channel. The size of this XML encoding is 6354 bytes. 
This could clearly be reduced by removing extraneous white space and potentially 
compressing the file with a standard compression algorithm or tool. Such a compression with 
gzip, for example, provides a file size of 657 bytes, which is nearly an order of magnitude 
improvement. 
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Encoding this example in the unaligned packed encoding rules results in a file of size 56 bytes. 
That is four METARs in the space normally needed to encode 56 (or potentially 64) characters. 
Note that the original, raw METARs are of lengths 74, 79, 72, and 84 characters, respectively. 
The uPER encoding offers a significant savings in data that would need to be transmitted. This is 
with only a minor loss in information. Specifically, some precision was lost in the time values 
(within 10 minutes), the tenths value in the hourly temperatures within the remarks, and 
potentially a few degrees in direction for each of the provided directions. 


B.3 Weather Polygon Encoding 

Because many relevant weather products are not currently available in machine -readable 
formats, the example provided here was manually generated based on a real-world forecast 
provided as an image file. Section 2.3 provided an example of a turbulence forecast in Alaska 
(Fig. 3). That figure is provided once again here (Fig. B3) for reference purposes. Using this 
image, the polygon encompassing St. Lawrence Island was chosen to encode. A similar polygon 
was drawn using Google Earth (see Figure B4) to obtain lat-lon values. Using those lat-lon 
values, the appropriate geohash values were determined. 
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Figure B4. Turbulence forecast polygon over St. Lawrence Island redrawn in Google Earth. 


Equipped with the information provided on the original forecast image and the approximated lat- 
lon values for the polygon, the weather polygon can now be described in the new ASN. 1 schema. 
The information from the image that is relevant includes the issue (or forecast) time (1300 UTC 
Wednesday), valid start time (1200 UTC Wednesday), valid end time (0000 UTC Thursday), 
altitudes, and predicted turbulence intensity (“OCNL TO CONS MOD”). Based on the set of times 
here, the reference time in the TAIGA message header should be 1200 UTC because it is the 
earliest time to be referenced in the message. All three times for this payload (1200 UTC, 1300 
UTC, and 0000UTC the next day) will all be described in 10-minute steps from the reference time 
(0, 6, and 72, respectively). Upon encoding this information using the XML encoding rules (XER), 
the following XML document is produced. 


<TAIGAMessage> 

Creference -time> 

<hour>12</hour> 

Cminut e >0</ mi nut e > 

</ reference -time > 

<day><friday/x/day> 

<payload- sequence > 

<wxpoly > 

<WeatherPolygon> 

CtypeX turbulence / >< / type > 

< t it le > OCNL TO CONS M0D</title> 

<polygon > 

<GeohashString>b5ptlqy</GeohashString> 
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<GeohashString>b70pptl</GeohashString> 

<GeohashString>b7212p6</GeohashString> 

<GeohashString>b5q7tb5</GeohashString> 

<GeohashString>b5md2fv</GeohashString> 

<GeohashString>b5jxtrw</GeohashString> 

</ polygon> 

<validTime>0</validTime> 

<validTimeEnd>72</ validTimeEnd> 

<forecastTime>6</ forecastTime> 

< f 1 ight Le vel > 

<baseAltitude>CK/baseAltitude> 

<ceilingAltitude>450</ceilingAltitude> 

</ flightLevel> 

</WeatherPolygon> 

</ wxpoly > 

</payload- sequence > 

</TAIGAMessage> 

That XML data takes 1189 bytes to encode, which could be reduced as discussed in the previous 
section. When this same sample is encoded using the unaligned Packed Encoding Rules (uPER), 
the space required to store it is only 55 bytes. Note that these 55 bytes completely describe the 
weather polygon including its boundaries (6 vertices) and meteoroconditions associated with it. 
Also note that other polygons could have been included in this message, but the manual process is 
somewhat cumbersome. When such predictions become available in a machine -readable format in 
the future, conversion to this ASN. 1 version can be better automated. 
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